Having a good initial estimation of effort makes a project fail or succeed. However, preliminary estimations are the most difficult to calculate, the less accurate, and the most binding.
This is the standard graphic that the software industry uses to show the possible distortions in estimations. It’s known as the uncertainty cone:
Usually, software companies don’t prepare good estimations. For developers, estimations are a kind of curse, so they don’t pay the sufficient attention that they deserve.
Common errors in estimations are:
- The time and effort needed to prepare a good estimation are underestimated.
- There are unclear requirements and continuous change requests.
- New projects are different from old ones. Each new project has its own characteristics.
- Usually, the size of the project is underestimated.
- Many times estimations are manipulated to fit available resources.
Despite the fact that there are a lot of reasons to pay attention to estimations, some of these reasons are not so obvious at the time the estimation is done. The consequences vary, but for example, companies can lose bids because of overestimations (high prices) or end up with an unsatisfied client because of underestimated projects, when they are not able to complete the project by the date they committed too.
A good estimation makes a project more predictable. There are several methods for estimations that can be grouped by:
Empiric methods that don’t use algorithms (Heuristic):
- Expert judgment
- Similar projects
Methods that use some kind of algorithm (Parametrics):
- Function Points
- COCOMO
- COCOMO II
- Adjusted Use Case Points.
Each one of these has its pros and cons. The important thing to do is to analyze and chose a method that we consider to be appropriate for our organization, and then perform a continuous refinement while we use it.
Having a method is very important because you change the focus of discussions, analyzing the scope and complexity of the work to be done, instead of discussing perceptions (i.e. if your estimation is too high or low).
No matter what method of estimation we use, the most important thing is to start having a good definition of scope (i.e. use cases).
It’s important to understand that if we overestimate projects, in the end, we will use as many resources as we estimated just to match this estimation. It’s a fact!
When we talk about software development estimations, we consider effort, but then this effort will be transformed in costs and planning. As we said before, we have to take into account that each estimation has an error rate and this error rate also affects costs and schedules:
The standard steps to prepare an estimation are:
-
- Define the scope: list of functionalities (use cases) and their complexity.
- Apply the selected method; calculate the hours of work needed (effort) for each type of task (analysis, development, testing, etc.) without taking into account which team will do it.
- Based on this effort and the company unit cost for an hour of work, calculate the total cost of the project.
- Analyze the tasks to be done and which of these tasks can be parallelized.
- Define the team and the time needed for each task.
- Prepare the planning and project schedule.
- Finally, with the detailed assignment of resources, prepare the Business Plan which contains the monthly cost in order to have a predictable cash flow.
During the project, it is very important to measure the actual number of hours of work in order to monitor estimated vs. actual effort, in order to refine future estimations.
Although initially the error percentage can be high, as we refine estimations with actual data, we can achieve reliable estimations in a reasonable period of time and also count on more predictable delivery dates.
