Estimating a project

When a project or collection of projects is in the idea or concept stage, you want to put together a high-level estimate to see whether or not the project is worth pursuing. You typically do not want to spend too much time working on a detailed estimate at this point, since you do not know if the idea is a worthwhile. Basically, you just want to know the relative magnitude of the effort. While you may be asked to provide a high-level estimate of the cost, the business people are also struggling to try to understand and quantify what the benefits of the project will be.

The most accurate way to estimate a project is usually to build a work breakdown structure and to estimate all of the lowest level individual work components. This is a bottom-up approach. It is also the most time consuming and is not appropriate for the initial estimating that you do early on in the funding and prioritization process.

Instead, you will want to utilize a top-down approach, trying to gain as much estimating confidence as possible while also taking as short a timeframe as is practical. To give you a few examples, the following are all top-down techniques that should be considered. Depending on the project, you may find that one or more techniques will work especially well. If you think the effort is large enough to be considered a program (collection of projects), then you need to take your best guess at breaking it up into a corresponding set of projects and then estimate the projects at a high level.

Partial Work Breakdown Structure (WBS)

In this approach, you would start building a traditional WBS, but you would only take it down one or two levels. At that point you would estimate the different work components, using your best guess, or one of the other estimating techniques listed here.

Previous History

This is by far the best way to estimate work. If your organization keeps track of actual effort hours from previous projects, you may have information that will help you estimate new work. The characteristics of the prior work, along with the actual effort hours, should be stored in a file/database. You then describe your project in the same terms to see if similar work has been done in the past. If so, then you have a good idea of the effort required to do your work.

Analogy

Even if you do not keep actual effort hours from previous projects, you may still be able to leverage previous work. Analogy means that you describe your work and ask your organization whether a similar project has been done in the past. If you find a match, see how many effort hours their project took and use this information for your estimate. (If the organization does not track actual effort hours, find out how many people worked on the project, and for how long, and then adjust the hours as needed.) Analogy is similar to the Previous History except that in the Previous History technique you have some structured method to compare historical projects to the one you are estimating. In the Analogy technique you do not have all the facts, so you are relying instead on comparisons with prior projects that seemed "similar".

Expert Opinion

In many cases you may need to go to an internal or external expert to get help estimating the work. For instance, if this is the first time you have used a new technology, you may need the help of an outside research firm to provide information. Many times these estimates are based on what other companies in the industry are experiencing. You may also have an internal expert who can help. Although this may be the first time you have had to estimate a certain type of project, someone else in your organization may have done it many times.

Parametric Modeling

To use this technique, a pattern must exist in the work so that an estimate of one or more basic components can be used to drive the overall estimate. For instance, if you have to implement a package in 40 branch offices, you could estimate the time and effort required for a typical large, medium, and small office. Then, group your 40 offices into buckets of large, medium, and small. Finally, do the math to estimate the entire project.

Ratio

Ratio is similar to analogy except that you have some basis for comparing work that has similar characteristics, but a larger or smaller scale. For instance, you may find that the effort required to complete a software installation for office A was 500 hours. There are twice as many people in the B office, which leads you to believe it may take 1000 hours there.

Estimate in Phases

One of the most difficult aspects of estimating projects is that you do not know exactly what work will be needed in the distant future. To reduce the level of uncertainty, you can break the work into a series of smaller projects and only give an estimate of the most current project, with a more vague estimate for the remaining work. For instance, many times you can provide a high-level estimate for an analysis phase, during which you will gather business requirements. After you have the requirements, then you will be in a position to estimate the rest of the project (or at least the next major phase). At that point, management can again do a cost-benefit calculation to determine if it makes sense to proceed with the rest of the project.

Summary

When you want to do a quick estimate of project cost, you want to use some type of high-level, top-down approach. Depending on the characteristics of the project and the type of information you have available, these approaches can actually be very accurate. Worst case, they should at least give you a decent ballpark estimate. From an expectations standpoint, this type of high-level estimate should be 25% to +75% accurate. That is, if you estimate the cost of the project to be $100,000, you would expect the actual cost to be in the range of $75,000 to $175,000. If your management or customer would like more accuracy than that, they need to give you more time to allow you to uncover more details, or lay the work out at a lower level.