I’ve been contributing to a stream on the ISBSG discussion forum on LinkedIn recently, and it amazes me, though it shouldn’t, that estimating continues to exercise so much discussion. Part of it boils down to the confusion of price and estimates. The myth persists that an estimate is a quote, but it cannot be, as an estimate will only be 100 percent accurate at delivery.
In reality, estimates are approximations based on models. That is true with expert estimating, as much as it is with SLIM, SEER and COCOCMO. The quality of the model depends on the quality and completeness of the input data.
An estimate is the most accurate view of the likely effort needed to deliver a specified set of tasks in a defined period and to a set quality, given the quality of the information available at the time the estimate is created. With large projects, estimates should be refined over time.
So, why go with parametric models rather than expert estimates? The simple answer is that over time, parametric models have been proven to be much more accurate than expert estimates. Or, maybe I should say, they are much less inaccurate than expert estimates.
Expert estimates are done by highly skilled people. Studies show that they are as likely to be wrong as right – see our Trusted Advisor Report – though when experts create a model based on historical data, they can be better.
In EDS, we used to think of the estimating process as if it were a mini-project in its own right, and I think that is still a valid proposition. You gather the data, you process it, and doing so, you identify risks associated with the information you have been given. You have to surface and manage the risks, and your estimate must indicate where the risks lie. FPA allows you to size a requirement, but a poor requirement leads to an inaccurate size measure. You must record the potential for growth as part of the sizing process and identify the risks to the project.
The worst case I ever saw was a company who had poor estimating skills and didn't recognise the risks associated with a wildly sketchy requirement. We were brought in as the programme was being canned. The original requirement was counted by my team at 7,000 FP, but we marked it as a red risk for lack of detail and potential for extreme growth. The final size was 30,000 FP and growing. They fixed the price based on the original requirement, didn't revisit the estimate, and then wondered why it all went wrong.
Many projects use multiple methods for delivery, so when you're creating your estimate you have to simplify the model so that the variables are manageable. Trying to take every variable into account means that by the time you deliver your estimate, you run the risk that the work will have already been done by someone else. In any case, if you have no size measure and no risk register associated with the measurement, you won't have a viable estimate.
An estimate is an approximation to enable you to manage your financial exposure, set a budget, construct a plan and build a team to deliver it. If the risks are too great and unmanageable, don't even start the project. Iterate the process until you can deliver a meaningful estimate, that way you are more likely to deliver the project successfully.
Managing Director, DCG-SMS