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.

Impact of Incorrect Estimation

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.

Incorrect project estimation hurts both vendors and customers in a fixed bid engagement.
Incorrect project estimation hurts both vendors and customers in a time and material engagement.

Levels of Project Estimation

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:

  1. High level estimation: Order of magnitude estimation. This is a crude estimate based on the broad level functionality groups such as user management or third party integrations. This can be done even when the requirements are not completely clear. Error expectation is plus or minus 50%.
  2. Detailed estimation: Estimation based on detailed functionality listing. For example, here the User Management functionality would be further detailed out into smaller functionalities such as roles and responsibility metrics, adding a responsibility, deleting a responsibility and defining the roles of users. Error expectation is 15-20%.
  3. BOM (Bill-Of-Material) estimation: Here the estimate is a consolidation of the estimates of individual components. These components are identified in the software design and are at an implementation level. Because the software design is already done when the BOM estimation can be performed, this estimation is done for the upcoming development part only. Error expectation is 5%.

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.

What is a Good Estimate

“Accurate estimate” is an oxymoron.

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.

Simple Estimation Process Based on Fibonacci Numbers

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:

  1. Listing: In a spreadsheet, list all the items in rows.
    1. In case of high level or detailed estimation, the items are primarily the functionalities. But also make sure to add other tasks that could take effort, such as data migration or performance tuning.
    2. For the BOM estimation, the items are primarily the components that need to be implemented. But also make sure to add anything not covered in those, such as integrating these components.
  2. Choosing Anchor: Choose the smallest significant item from the list, and assign it a size as 1. (Some items could be insignificant in the sense that they would take miniscule effort compared to others. Ignore them for now.) We shall call this size 1 item as the anchor item.
  3. Relative Sizing: Now, for every other item on the list, assign a size that is relative to the anchor item. Ask yourself the question: “If the anchor item is 1, then how much would this item be?”
    1. Assign 0 size to insignificant items as they are too small to be counted.
    2. If you come across any item which is so big that you are looking at Fibonacci numbers beyond 8, then consider breaking the big item into smaller items and then estimate those individually. (You may use 13, 21 very rarely — almost never.)
    3. Some items may be smaller than 1, but still not insignificant to be zero. For such items, 0.5 may be reluctantly allowed (though it is not a Fibonacci number).
  4. Project Sizing: Now, sum those sizes. That will give you the project size as a number. It reflects what multiple of the anchor item size the total project is.
  5. Raw Development Estimation: Now, estimate the anchor item in terms of development effort in terms of development effort required. The unit of the effort is something like person-months, person-days, person-hours — depending on the level of estimation. Multiply with the project size to get the raw development effort needed for the project.
  6. Raw Project Estimation: Add effort for other lifecycle activities in proportion to the development effort. For example, for 8 hours of development effort you consider 2.5 hours of testing. Similarly, add proportional effort for management. Some times, there may be some other items specific to the project (such as data migration), and their estimates need to be added.
  7. Adding Buffers: This is where you add buffer. Among other things, the buffer would depend on how high the stakes are.

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.

Applying the Estimation Process at Different Levels

It is interesting that the same process may be applied to different levels of estimation.

  1. In a high level estimation, the items are large in size. So the effort may be estimated in terms of person-weeks or even person-months.
  2. In a detailed estimate, the items are much smaller in size. So the unit of effort estimation would be person-days or even person-hours.
  3. In the BOM estimate, the detailed functionality items are further broken into components. This is a highly granular level estimate. The effort unit is person-hours.

Why It Works

The process works because:

  • It is easier for a human mind to do the relative sizing. So, once you fix the anchor item, imagining the effort for other items in multiples of that becomes easy.
  • The actual estimation is done only on the anchor item. The anchor item being the smallest one, it is easy and quick to estimate.
  • The insistence on using Fibonacci numbers only, as opposed to any numbers, increases the productivity and prevents unproductive over-thinking.

Factors Affecting Estimation

Mahesh Dedhia, AVP of Citius Tech, identifies a few factors that impact the estimation:

  • Past experience: Most important
  • Level of expertise of your technical team with respect to the technologies involved
  • Maturity of the technology, Productivity of the technology
  • Maturity of the customer organization, dynamism in scope & prioritization
  • Availability of support system, subject matter expertise
  • Project management methodology and maturity
  • Acceptance criteria: Level of quality requirements, process requirements
  • Visibility into competition
  • Risk appetite

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,

  • What would be the impact if we use technology A instead of technology B on this project?
  • What would be the impact if we use more number of junior resources instead of senior resources?
  • What is the change if the acceptance criteria is made more stringent?

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.

Project Estimation in a Group

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.

  1. Each player is given the estimation cards — one card for each number. Thus, everyone gets 5 cards.
  2. One player reads the item aloud.
  3. Every player thinks of the item size and chooses their card with that size. The player then places the card on the floor face down, so that the number is not visible to others. This step is called voting.
  4. Once everyone has voted, a “show” is called. The cards are then turned around so that everyone’s votes are now visible.
  5. If all the votes are in agreement, that size is assigned to the item and you move to the next item. (Go to step 2 and repeat.)
  6. If all votes are not in agreement, then the players have a debate on it. Especially the player with the lowest vote and the player with the highest vote are asked why they assigned that size to the given item. This discussion results in clarifications and evolves a common understanding on the item. After the discussion, a re-vote is taken on the item. (Go to step 3 and repeat.)

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.

Summary

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.

Software Project Estimation Made Easy

Leave a Reply

Your email address will not be published. Required fields are marked *