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.
Function Point Analysis
Where Wideband Delphi uses people's opinions about how long a task should take, Function Point Analysis tries to be more objective.
In FPA you read the specification of the software, identify all the transactions, files, reports, forms and so on, and then break those down into their constituent elements to be classified according to how complex they are and assigned numerical values - the function points.
These are then totalled up and if you know the team's productivity (in function points per hour) you should then know how long the project should take. The theory is that different people running FPA on the same project should come up with the same answer. In reality, well-trained people can get very close but FPA is more than a little complicated to learn.
Alternative
A radical alternative to estimating is not to do it at all - though needless to say this approach won't suit every company of project. One software house, tasked with maintaining a company's internal applications, had a SLA (Service Level Agreement) which said that the only thing they had to do was to give an estimate of how long a fix or enhancement would take within two days of the request being received.
The estimating took so much time that there wasn't any time left to actually carry out the work. A long backlog of work also ensured that nothing happened fast. The whole system of work was broken and needed a radical change.
By looking back at past work they found that nearly all fixes took about five man days so they stopped estimating, scrapped the nonsensical SLA and simply charged a fixed fee for the year. Some fixes took fifteen days but many took as few as three so no-one lost out. Removing the burden of estimating freed up staff to do the work, the backlog was cleared and everybody was happy.
No pain, no gain
Estimating is a pain but it needs to be done right. The Extreme Programming method says that only the person doing the work should estimate how long it will take. Wideband Delphi uses the team approach to get 'buy-in'. FPA and Agile Programming both advocate measuring the work in more or less formal ways, based on past performance.
However you do it, though, if you get it right you have far more chance of your project coming in on-time and on-budget. And that, after all, is the ultimate objective.
Further reading
- Book: Software Engineering Economics by Barry Boehm http://www.amazon.com/gp/product/0138221227/sr=8-1/qid=1145964013/ref=pd_bbs_1/104-8200390-9611916?%5Fencoding=UTF8
- Book: Applies Software Project Management by Andrew Stellman & Jennifer Greene http://www.amazon.co.uk/exec/obidos/ASIN/0596009488/qid%3D1145981862/026-6215175-2133257
- Web Site: Karl Wiegers' Process Impact http://www.processimpact.com/pubs.shtml
(especially Stop Promising Miracles http://www.processimpact.com/articles/delphi.html) - Web Site: Longstreet Consulting http://www.ifpug.com/default.htm
(especially The Fundamentals of Function Point Analysis http://www.ifpug.com/fpafund.htm) - Blog: David J Anderson's Agile Management http://www.agilemanagement.net/Articles/Weblog/blog.html (especially From Worst to Best in 9 Months http://www.agilemanagement.net/Articles/Papers/TOCICOBarcelona.html)
