First case was to understand where actually the estimation went wrong. For us it was many factors. Following are few of them
- Bad scoping - Requirements are not properly understood
- Poor understanding of product or requirement
- Over confidence
- Not considering the overhead of design/documentation/review/implementation/support
- No resource categorization
- No statistical analysis
- Poor estimation techniques
Bad scoping obviously need to be addressed by business analyst or anyone who gather requirement. Who ever plays this role should have a fair understanding of the project/product and should be good communicator. All the requirements should be properly documented and validated through few faces until no clarifications are pending before sending it to the estimation team.
Estimation software is tricky and as I see it there are no right or wrong way. If you are an estimator my suggestion is stick to the estimation technique that produce correct results for longer period. To do that obviously you need to have good understanding on available estimation techniques and statistical analysis of estimation data with actual project data. For estimation I would suggest this book. It's wonderful read if you are really suffering from the estimation problems. Lastly estimation should be an estimation. It's not exact figure! You cannot give an estimate without a probability. And getting your estimations to continuously hit 80-120% of actual targets are the best estimations. But still there may be odd project that shoots off the tracks. Thus controlling the project through correct project management techniques in mandatory even if you have the best developers in the word.
Even though we follow a waterfall approach on estimation to be given out to the customer, we do not use it for the internal work planing as it self. After the estimation is done there might be more in depth analysis or changes to scope. So we will re estimate iteration wise with the detailed work breakdown and project planning will happen to match or control the project within the acceptable level of deliverables/etc. This has helped us to get feedback on the original estimation errors and take corrective actions. Also it has enabled us to follow an iterative process even though the original process is waterfall.
So that is how it works!
But I have a complaint to lodge with current university curriculum which grossly ignore critical engineering practices like estimations which should be covered at least in brief as it's a core role of any software engineer. Anyway hopefully in future this will be corrected for the betterment of the industry!
