Beware These Common Estimating Errors
Tom Mochal, President of TenStep, writes a regular column on his web site titled TenStep Project Management Tip of the Week. This one is from 12/2/09 and is well worth committing to memory. But remember that Tom is talking here about estimating for Information Technology and Software Development projects.
The estimation process is both an art and a science.
However, once you learn good estimating processes and techniques, you will hopefully be able to move more toward the "science" side of estimating and rely less on the "art" side. You can get better and better at estimating, but by nature you can never be perfect. Here is a list of common estimating problems that should be avoided.
Assuming higher quality work than you or your team can deliver.
This problem includes estimating based on building at a certain level of quality the first time, i.e. without resort to any feasibility trial work. However, as the project is executed, you realize that your ability to build to this high level of quality is limited, resulting in overages for rework, bug fixes, retesting, etc.
Committing based on available budget.
In this case, the client has a fixed amount for the budget. The project manager thinks there is a chance he can get it done within available budget, so he commits based on that number. This is similar to the best-case scenario problem below.
Committing to best-case scenario.
The client wants it done as quickly as possible. Your manager wants it done as quickly as possible. You think it can be done quickly. However, you get into trouble because you commit based on what it would take to complete the work if everything went right. You might even think in terms of a range of effort for the work, but then too often you end up committing to an estimate at the lower, or optimistic, end of the range.
Failure to validate an Old Estimate when a new team is in place.
Usually a project team is formed to define the project, build the schedule and budget, and then execute the project. However, sometimes the effort and duration of a project are estimated very early, perhaps because the information is needed as part of the yearly budget cycle. In these cases, a project team may be put together later and asked to deliver the work based on the high-level estimate that was done earlier.
If that happens, one of the first jobs of the new project team is to validate the estimate. You do not want to be in a position of having to deliver against someone else's estimate. If you do not validate or challenge the estimates early, the expectation gets set that you think they are accurate. The project manager should challenge the estimates early. If you agree with the estimates, then you proceed to deliver against that estimated effort, budget and deadline. If you do not agree with the estimate, now is the time to raise the red flag. This is better for the company as well. You may find out, for instance, that if your estimate is higher, the project cost / benefit no longer makes sense. It is better to find that out earlier rather than later.
Not recognizing estimating biases.
Estimating biases sneak into estimates all of the time. Some are optimistic biases and some are pessimistic. Optimistic biases will result in underestimating the work and can include:
- Not taking into account project risks, issues, miscommunications, etc.
- Tending to be optimistic in the first place
- Tending to think the work is simple
- Tending to think your team can accomplish more than they really can
Pessimistic biases will result in overestimating the work and can include:
- Having a bad experience on a similar project in the past
- Not really wanting to do the work. You estimate high and hope the project will be cancelled
- Tending to be pessimistic to begin with
Not taking all the work into account.
This is a common problem, especially with earlier, high-level estimates. You may just miss some major work that you did not understand to be a part of the project, such as documentation or training. Typically, however, you underestimate the size of deliverables that need to be completed, or you do not include all of the activities required to complete the deliverable.
Wishful thinking.
Anyone that has provided estimates of work knows that there can be pressure from your client to make the estimate as low as possible. Ultimately, the client wants to get what he needs for as little effort (and cost) as possible. In many cases, there is a tendency on the part of the estimator to get caught up in that mindset as well. The estimator ends up "wishing‰ the work gets completed within the client expectations.
Your personal biases are always there.
The key is to recognize and counter the biases where you see them. This will help you prepare estimates that are as reliable as possible.
Footnote
Tom uses the word "reliable". We would translate that to mean "practical and most likely". In one of our software projects we would get estimates of cost (amount of work) from our chief programmer. We soon learned to take this number and multiply by three - yes, three! That accounted for the programmer's optimism, iterative rework, and the project's overheads!
|
