Why you need estimation

gallery

Estimating is the black art of project management. It is no-one's favourite task. But like it or not the success or failure of a project depends on accurate estimates. Pessimism can kill the project before it starts as the client may think it is too expensive. Overly optimistic estimates, on the other hand, can cost you or the client dearly when the project overruns.

Why Estimate?

If you propose doing anything these days, someone is bound to ask "what will it cost" or "how long will it take", which, when you are building software, is almost the same thing. For small projects, these questions are relatively easy to answer.

Trouble rears its ugly head, however, as the project size increases. With multiple programmers, dedicated testing teams and interfaces to existing systems the time required for larger projects seems to increase exponentially.

How to Estimate

With the fallibilities of the human memory and psyche, we tend to forget our failures and overestimate our abilities. Referring back to the times that specific tasks took during previous projects can help you but only if you can find similar tasks to compare.

Likewise, if you rely on one person to carry out the estimating you will get an answer but nothing to gauge it against. Different people have different ideas as to how long something will take to do. Some people think from the bottom up, estimating all the little tasks and the adding the time up. Others think from the top down, estimating the high-level tasks and dividing the time into the sub-tasks.

Bottom-up people generally come up with larger estimates than top-down people, if only due to the granularity of their estimating. A top-down guy may say a task will take eight hours but a bottom-up person might say that the ten sub-tasks will take an hour each.

The skill, knowledge and experience of the people involved must also be taken into account. An experienced, highly skilled programmer may be 10 times faster than a rookie but take him or her out of their comfort zone and their productivity can plummet. It is natural for people to estimate based on their own experience and because people are different, so are their estimates.

Wideband Delphi

Getting many people involved in estimating is one way to get closer to 'the truth' and it gives the project team a sense of ownership of the figures produced. But if you just take the mean values of the different estimates the end figures won't match anyone's first estimate so you run the risk of destroying any 'buy-in' the team might have from being part of the estimating process in the first place.

The Wideband Delphi method helps development teams reach a consensus about the estimates for a project so giving you more accurate figures and a more committed and cohesive team.

It works like this: a team of three to seven estimators from the project team make individual estimates and then, all together, with a moderator, analyze their assumptions and issues about the tasks, refining their estimates as they go. No one reveals their numbers except to the moderator and he or she draws everyone's project totals on a board, as crosses on a number line. The anonymous aspect of this method helps eliminate bias based on preconceptions of people's status or differing objectives.

Four rounds of estimation should deliver close estimates and the average (discounting outlying values) should be an accurate reflection of the team's thinking.

Email to a friend

Print this page