Project estimation is one of the most important and early activities in a software project. It is tricky especially in project outsourcing scenario where it is done before the project is allocated. Project estimation is used to create the expectation and many times also to arrive at the financials of the engagement.
Many times, project failures are attributed to estimates that were either too low or too high. The following figures illustrate the impact of incorrect estimation on the vendor side and the customer side, for different pricing models..
When a project outsourcing is considered, the vendor is asked to do the project estimation first, and the project allotment is decided based on that. This means that the vendor is not sure of project being allotted to them at the time of estimation. For this reason, there is a natural limitation on how much time and energy they want to expend on the estimation.
The estimation is therefore realized at different levels:
While the BOM estimate is quite reliable, it is not available till the software design is done. Also, it is possible only with technologies that allow explicit separation of software components.
A high level estimation is used for no/no-go decision, without doing much time or energy investment. A detailed estimation is then prepared to get a better handle on the budget and schedule expectations. Both these estimations come from the functional understanding of the software. A BOM estimate, on the other hand, is a technical estimate. But because it is not available until a reliable design is done, it is not commonly done.
All estimates are inaccurate, and they are also valid only within the frame of assumptions.
To understand this point, think about some spot that is 5 miles away from where you stay and ask yourself how much time you would take to reach there. This is your estimate. The actual time that you take to reach there will be different from this estimation. Some times it may be more, some times it may be less. It would also depend on factors outside your control such as traffic conditions.
Such uncertainties exist in software development too. Some times a downtime is caused by a machine breakdown. Some issues are so nasty that they take quite long to detect and fix. What is more, the psychological state of a programmer can affect their productivity up to 10 times. Clearly, you can never take into account all these factors during estimation. Therefore, the goal of estimation is not to be accurate, but to be reasonably close.
We shall call an estimate good if it holds reasonably. The actual time will be some times less and some times more. Your estimate is an optimistic estimate if the actual time is more than this estimate most of the times, and it’s a pessimistic estimate if the actual time is less than the estimate most of the times. While estimating individual items, you should avoid both, otherwise you will encounter the problems covered above. Remember that you can always add a separate buffer to your estimates at a later stage, so you do not have to blow the estimates of individual activities to play safe.
In software projects, there are many activities that are independently estimated. A good estimate is the one which holds reasonably as a sum total. Some activities will still take more time than estimated and some will take less.
Arriving at such a workable estimate is the goal of the estimation process. A complex process does not ensure that your resultant estimate will be good. We therefore advise that you stick with a simple process that can be executed quickly and with ease. Below we present to you such a process.
In this process, relative estimation of items is done using Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21. Commonly used numbers are the single digit Fibonacci numbers namely 1,2,3,5 and 8. The next two numbers 13 and 21 are used very rarely, if at all.
Here is the 7 step process:
Keep in mind that this process will give you the effort estimation for the development process. It can then be converted to cost estimation and project duration estimation. Any items outside the development process (such as web hosting, travel) needs to be considered separately.
It is interesting that the same process may be applied to different levels of estimation.
The process works because:
Mahesh Dedhia, AVP of Citius Tech, identifies a few factors that impact the estimation:
Additionally, an article from Greycampus lists the various ways in which project estimations are made, under the section “Tools for More accurate Project Estimations“. Further, a few gems of advice around some specific scenarios can be found in a PMI article.
The factors covered above typically affect only 2 of the 7 steps. They affect the anchor item’s estimation in step 5 and/or the buffer in step 7. Therefore, when one or more of these factors change, it is easy to re-estimate, as you do not need to repeat steps 1-4. This point is important, because, without investing a lot of effort, a vendor will be able to answer frequently asked questions such as,
Acism uses some of these factors to deliver budget flexibility. Further, Acism’s buffet menu offering delivers more flexibility on how the work is divided among different organizations, and that can result in further impact on the project estimation.
This estimation process can be used very effectively in a group, using the planning poker technique. This is applicable especially to the Relative Sizing step (step 3), which is done after you have chosen an anchor item.
To play the planning poker, you need estimation cards — which may look similar to playing cards. An estimation card has a single digit Fibonacci number (1, 2, 3, 5 or 8) printed on it.
In practice, planning poker is found quite valuable. It works against personal biases and blind spots. As a bi-product, you also get a common understanding of the functionality established among the team members.
Project estimation is an important early activity. It can also be quite tricky. Many times, project failures are attributed to incorrect estimations. Therefore, too low or too high estimation needs to be avoided.
However, estimations are never accurate. The goal of the project estimation process is therefore to arrive at a workable estimate, which holds reasonably good overall. It is also desirable for the estimation process to be simple and easy, so that one may be able to carry it out with minimum time investment.
We have presented a simple process of software project estimation. We also reviewed the factors that can affect the estimates. The process can be utilized to do estimation at different levels. It may also be used to carry out the estimation by multiple people in a group.