Early in the SAPM course  we discussed estimating size and effort for software projects. We know this a nearly impossible task but a necessary one. Despite all the effort put into techniques and formulas that are supposed to help with this problem software keep being delivered late, incredibly late or never. Maybe what needs to be adjusted is not the process of estimating time and costs but the process of planning a project. We should instead expect to deliver a project with a few missing components that we can add later on. (This could explain the success of agile development: if a nonessential component is not ready, the project can still go on and be delivered)
Why is estimating project cost and size important? Because companies need these estimates to plan cost and human resources to allocate to the given project. Good estimates allow companies to commit to delivery dates for its product and not have to deal with unhappy customers, while bad ones lead to projects going over budget, over schedule or even end up as runaway projects.
How is the world coping?
In an endeavour to handle this problem various techniques and formulas have been developed to help with time – effort estimation. As previously mentioned none are a perfect solution and it seems that the industry has come to accept that estimates are likely to be wrong, but they need a starting point so the described techniques will continue to be used.
There are three major techniques used for effort estimation: three point estimates, Wideband-Delphi estimates and COCOMO.
Three point estimates
The three point estimate is a formula for computing an effort estimate as a weighted average of an optimistic, a most likely and a pessimistic estimate.
In my opinion this is a simple and fast technique to get a rough effort estimate. Since we already know that estimates given at the beginning of a project are likely to be wrong and therefore a waste of time, it is preferable to move on as soon as possible.
Wideband-Delphi estimating is a techniques for computing time estimates that requests the presence of a group of experts. They repeatedly discuss the implications of the project and give they own blind and anonymous estimation of project duration until all estimates are roughly similar. Giving a blind, anonymous estimate ensures the result is not influenced by external factors such as peer pressure.
COCOMO is a formula for establishing effort estimates based on previous experience. This requires that all previous projects are well documented. In my opinion, relying on previous experience is the best approach; however, it is likely to fail if the team changes as it is quite often the case in software development teams. COCOMO will be delivering optimistic estimates if suddenly several team members are replaced by other less experienced members; moreover the a team’s dynamics generally impacts the teams performance.
A technique that would help with damage control early on in the development process would be periodic reviews of the effort estimates they have committed to. This especially important as there are several factors that unknown at the beginning of a project and helps adjusting the resources to help with delivering the product.
Maybe there is light at the end of the tunnel
During an internship, I got to participate in my team establishing new projects to work on, and the process worked along the lines of “What can we do in the next year?” and “What can we build the the next three months” rather than “How long will it take us to build this project?”. The yearly plan was vague and most likely to change but the quarterly one what we were really trying to achieve. In addition, the company’s policy was: “if you finish everything on time, then you haven’t challenged yourself”, so teams were encouraged to plan for more than they could realistically achieve in the given time. This also means that it was expected that teams would not attain all their goals for that period. Moreover, we were working on a project with frequent releases, so this made the concept of deadline rather non-existent, as anything that was not ready for release could wait for the next release.
I am sure many of you are wondering what keeps people from slacking off? The answer is: company culture. But this is another story. The frequent review of goals as well as the lack pressure from the company were very helped the team stay on track while trying to quickly move forward with the development process.
In my opinion, this model can work even for companies with less frequent releases. As long as they prioritize the features they are trying to build. They can start by building the most important features or components first, and put everything else in an “if we have time” category.
As we appreciate the importance of structuring a large project: planning and allocating resources to avoid waste, experience has shown it it almost impossible to control all the elements that influence the successful completion of a software project. Experience has shown that adding structure to the process of building software is impossible and we should learn to live with the unforeseeable.