Useful Estimation Techniques for Software Projects

The Importance of Good Estimation

Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on a project. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.

In my experience, making estimates of time and resources required for a project is usually a challenge for most project teams and project managers. It could be because they do not have experience doing estimates, they are unfamiliar with the technology being used or the business domain, requirements are unclear, there are dependencies on work being done by others, and so on. These can result in a situation akin to analysis paralysis as the team delays providing any estimates while they try to get a good handle on the requirements, dependencies, and issues. Alternatively, we will produce estimates that are usually highly optimistic as we have ignored items that need to be dealt with. How does one handle situations such as these?

Useful Estimation Techniques

Before we begin, we need to understand what types of estimates we can provide. Estimates can be roughly divided into three types:

1. Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.
2. Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.
3. Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.

Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.

Doing an order of magnitude estimate

This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the best estimate we can provide.

1. Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
2. Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
3. Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on. These weighing factors will differ based on the team and project and should be reviewed after the project to help get better values the next time. Add together all these values for each task to get an estimate of time and resources required.

Figure 1. A sample table used for doing an order of magnitude estimate.

Doing rough and fair estimates

These estimates can be done when you have a good idea of the tasks to be done and how to do them.

1. Those who will do the actual work are the best people to do these estimates. One then can add up all the estimates from different people to get the final estimates.
2. Ensure you collect estimates on the three variables of time, people, and infrastructure/material needs.
3. Break down tasks to as detailed a level as possible. As mentioned previously, it can help to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task. Break tasks down to a granularity of eighty hours or less.

Conclusion

The preceding techniques can help one achieve better estimates. Review estimated needs versus actual needs after every project. Identify what was correct and what was wrong. This will help you improve the next time. As with many other activities, experience will help you get better!

Author Information: Sanjay Murthi is President of SMGlobal Inc. He has over fourteen years of experience in the software industry in a variety of roles and responsibilities. He now helps companies to review and improve their software definition, development and delivery process. He can be contacted at smurthi@smglobal.com.