Brian Marick has a pointer to this piece on Martin Fowler’s bliki: MF Bliki: WhatIsFailure
The Standish Group’s CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001’s figure of 28%.
But what do we really mean ‘failure’? The chaos report defines success as on-time, on-budget and with most of the expected features. But is this really success? After all Windows 95 was horribly late yet was extremely successful for Microsoft’s business.
Rather than saying that a project is failed because it is late, or has cost overruns – I would argue that it’s the estimate that failed. So the CHAOS report isn’t chronicling software project failure, it’s chronicling software estimation failure.
I’d add:
— Project fail to re-estimate or estimate iteratively. The initial estimate, made in the fuzzy front end of the project is not revisited as details emerge, assumptions are tested and scope changes. I like to do an initial estimate, re-estimate at design time, and then do engineering estimates when the technical work is assigned. I also like to re-estimate based on actual data a la “yesterday’s weather.”
— In many cases the “estimate” is, at best an opinion, not supported by method, data, or review. When I work with teams to develop estimates early in a project, I use a couple of different estimating techniques, and then do a reality check using data from previous projects. An early estimate may not be precise, but it can be credible, if you put thought into it and document how you arrived at the estimate. Many projects choose to skip building credible estimates and go with “engineering opinion” — sometimes called an incredible estimate.
— Sometimes senior management sells a project based on a low estimate, knowing full-well that the estimate is way understated. They know they wouldn’t obtain funding or approval if a more accurate (and larger) figure were proposed.
