A research published by the Standish Group indicates that in 2004, 54% of projects where delivered late, 18% failed, and only 28% on time and within budget. The same report indicates in 1994, the average project schedule overrun was about 120% and the average cost overrun was about 100%. No doubt that to estimate a software project accurately is a challenge for all organizations.
An accurate estimate does not only help for a better budgeting, but also come with additional benefits. To list a few based on the book Software Estimation from Steve McConnell:
- Better planning – A project plan is often setup based on the estimate. If the estimate is accurate and realistic, the project plan will be more useful for progress tracking. Also you will have a more accurate view of resource availability.
- Better task completion in terms of documentations, testings, training, etc – If the estimate is not accurate, resources and time will be used up on programming and these other tasks’ schedules will slip or even be omitted.
- Better quality – More accurate estimate, better schedule, and less pressure to finish things within unrealistic time generate a higher quality!
So in my practice of estimating software project, I have been following a few ideas also from Steve McConnel to make sure the estimate is more accurate. Below is a few of them:
1. Understand Cone of Uncertainty
The full article of the Con of Uncertainty can be found here.
Basically the diagram shows that in best case scenario there is a -20% to 25% error after user interface design complete, which is still manageable. However if estimating in a early stage such as requirement complete, there will be a -33% to 50% error, which is difficult even for a skilled project manager to navigate to project completion successfully.
Because early estimate is always inaccurate, it is obvious that we should estimate the project as late as possible, but in reality, this is a luxury we can’t get in every project. Most clients would want at least a ball park estimate at front to evaluate whether the project can be funded and meet business target. To address this issue, the same book presents a method to use multiplier to compensate the estimate error in order to get a “most likely” estimate.
|Phase||Possible Error on Low Side||Possible Error on High Side||Range of High to Low Estimates|
|Approved Product Definition||0.5x||2x||4x|
|User Interface Design Complete||0.5x||1.25x||1.6x|
|Detailed Design Complete||0.9x||1.1x||1.2x|
Again, keep in mind, this is only the best-case accuracy – meaning the actual project can’t be better than it.
2. Do not be optimistic
Intuitively, when we estimate a project, we compare the work with a similar project from the past. We will think that the errors from past projects will not happen again, the learning curve from the past projects will not exist, and so on. However, this is not often the case. Studies show that both developers and managers have a optimism factor of about 20% to 33%. (van Genuchten 1991, Boehm 1981). So try not to be optimistic and reduce the estimate from developers because it will definitely cause an underestimate.
3. Include often omitted activities
In my own experience, often times the reason an estimate is not accurate is because omitting of certain activities. When we do estimate upfront, it seems okay to not include everything but just the critical ones. However, these omitted tasks can add up to a big amount of effort! Below are some of the tasks that can be easily omitted.
- Demonstrating software/prototype to customers or users
- Learning curve of 3rd party software packages
- Creating or importing test data
- Data migration/conversion from existing system
- Browser compatibility
- Security vulnerability scanning and fixing
- Deployment to client’s environments (UAT and PROD)
- Deployment and maintenance of multiple test environments internally
- End user training
- User guide
- Holidays and employee vacation days
The list suits my own situations. A more comprehensive list can be found in the same book I have been referring to, Software Estimation from Steve McConnell.
Software Estimation: Demystifying the Black Art, Steve McConnell, 2006