Software project estimation is one of the first steps to validate your new product idea. It’s the document based on which you’re going to choose a software provider. Unfortunately, very often these estimates are nowhere near realistic. That’s why we kept working on our estimating process until we achieved the most accurate estimates and now we want to share how we do it. A mix of three-point estimating method and parametric estimation proved to be the most effective one and I go into more detail about it in this article. You can also watch the video about it.
What is software project estimation?
Estimation is the 4th step in our process of evaluating the project before the development begins. Below you can see all of the stages that allow us to deliver true business value to our clients.
The go or no-go decision on developing a new product often depends on the estimation. These types of projects tend to be significant to the budget and resources distribution. That’s why getting an estimation and comparing it to your financial capabilities is a natural part of the process. A typical software project estimation consists of:
- cost estimation
- resources estimation
- effort estimation
Estimation focuses on the team composition and the amount of work in man-hours, needed to be done in order to deliver a project. The main reason for estimating is to avoid situation when the project exceeds the budget maximum or the expenses are higher than the profits expected from the finished product.
The basis of each of these methods is always project requirements specification. To estimate a project correctly we need to move past the evaluating stage. The documentation, with mapped out features and architecture, is our guideline. Based on the list of functionalities from that document we can focus on estimating the whole project.
Types of project estimation
Project management practices consist of a few methods of software project estimation. They all have their pros and cons and tend to work better on some projects than others.
There’s a top-down estimate where the starting point is the maximum budget value and the goal is to estimate features within the limit. A reversed bottom-up method focuses on dividing the project into smallest possible elements. Each element is estimated separately and the combined number of all individual parts of the project is the final value of the project estimation.
There’s a lot of different ways to estimate a project. Here at BoostHigh we prefer a combination of parametric estimation and three-point estimating method.
Three-point estimating method
Over the years we’ve managed to adjust our estimating process to make it as accurate and effective as possible. We use three-point estimating that combines 3 values:
- Optimistic
- Most likely
- Pessimistic
By using the equation to compute PERT (Program Evaluation and Review Technique) we’re able to get the most accurate results.
The estimation is based on the formula where Estimate = (optimistic + most likely + pessimistic) / 3
We calculate the values based on parametric estimation where our experience from previous projects and implementations are the source of our comparison.
Optimistic time estimation
The first value we establish is the optimistic scenario. There are certain variables that influence the estimation:
- our past implementations of this module
- the number of details about the feature in the documentation
- the dependance of the module on other features
If a module had been delivered before by someone in our team in a previous project, we’re able to assume it might take us a similar time to deliver the same feature again.
Most likely time estimation
We’re able to estimate the most probable scenario when we have a significant amount of data about the module. Usually the most likely value assumes that there might be a need for some adjustments due to lack of initial information.
We often count the unit cost from a previous implementation and scale it to the new project requirements. It’s more accurate than simply copying the numbers from previous projects.
Pessimistic time estimation
Three-point estimating method is so accurate because it also takes into consideration the pessimistic scenario. Just like I mentioned before there are variables that influence the time of the implementation.
If the requirements specification is vague, the difference between the optimistic and pessimistic value is going to be significant. However, with the right documentation those numbers are very close to each other.
PERT
Program Evaluation and Review Technique aka. PERT is the form of triangular distribution:
PERT = optimistic + most likely + pessimistic / 3
It focuses on the three values and measures the average time for each functionality. Instead of getting one ‘most likely’ value, you’re getting a more accurate number that has been calculated based on our experience and historical data.
Requirements documentation specification vs. software project estimation
It’s important to mention that the accuracy of the estimation is purely based on the quality of requirements documentation specification.
The more vague the documentation is, the bigger the difference between the optimistic and pessimistic value is going to be. Our estimating process takes into account this possibility. However, the estimation is always going to be more accurate with the properly prepared documentation beforehand.
What do we do when there’s little to no documentation?
In the ideal world the client delivers software requirements specification and we prepare software project estimate based on the information from the document. We all know the world is not ideal though. That’s why we’re also prepared to create an estimation based on our conversation with the client and an initial list of functionalities.
For a project without documentation provided we can create a system architecture proposal. We show the sample of the possible solution and base our estimate on that.
Summary
Software project estimation is like having an opinion, everyone can have a different one. The approach depends on our experience and the amount of available information. Many companies minimize project estimation to save the time of its employees. At the end, the client is left unsatisfied, and often with an unfinished product .
We learned that taking the time to truly evaluate the idea and proposing the most accurate estimation is a win-win approach in the long run.
We also recommend:
