We are currently involved in at least two conversations with large coroporate clients about how they can change their application development culture to adopt data-driven, parametric-based estimation, leaving behind the SME-dependent estimation that has been in practice for a long time.
One of the clients offers a lesson for the other: As a first step, the first client commissioned a six-sigma-based analysis of the variance in budget outcomes of application development projects and the variances in estimates compared to actuals. The goal was to identify whether the estimation process was sufficently under control to allow process improvement to be effective, or if the process needed to be brought under control first.
The results were clear: the variances were such that it was obvious to all, including senior management, that neither the project budgeting nor the estimation were repeatable. They were not under control. This was the justification and springboard for a change to a data-driven, parametric-based estimation process. We are discussing a similar approach for the second client. They have weak executive support for change and so the first step must be collecting data (or in some cases demonstrating that there is no data) to persuade the stakeholders that the problem is real and impacting the business.
Coincidentally, this month's (March 2012, Vol 15. No. 1 - although the print version is labeled "February 2012") Journal of Software Technology from DACS contains a great article from our friend Arlene Minkiewicz, entitled "Selling Your Software Estimate." It's well worth a read if your current challenges are similar to those I have described here.
What are your thoughts? Is it necessary to collect date in order to prove the value of software estimation? What's your approach?