The Chicken ITles are at work on IT project success rates
Did you know Standish Chaos reports ("70% of IT projects fail") have been well discredited? No? Stop using the numbers. We're bad at IT projects but we're not that bad. And considering what we're up against, perhaps we're not that bad at all.
I mentioned this at the itSMF Australia "LEADit" conference today (always an excellent conference BTW, be there next year!).
As this article Apocalpse No puts it
Part 1 of this article made fun of authors who claim that software engineering is a total failure — and [yet], like everyone else, benefit from powerful software at every step of their daily lives.
Catastrophism in talking about software has a long history. Software engineering started around 1966 with the recognition of a “software crisis“.
I wrote about Standish in my IT Skeptic awards for 2006
The Grand Sagan Candle for IT Skepticism goes to Robert Glass (in the Communications of the ACM 49:8, August 2006) for reportedly applying scientific method to one of IT’s many assertions, the Standish CHAOS Report. This is the one that gave us those oft-quoted numbers (known on this blog as “crap factoids”) “a staggering 31.1% of projects will be canceled before they ever get completed … only 16.2% [of] software projects that are completed on-time and on-budget. In the larger companies … only 9% of their projects come in on-time and on-budget”.
Glass points out the inconvenient fact that “Objective research study findings do not, in general, support the Standish conclusions” and makes some telling criticisms of the Standish methodology, which appears to be much the same as those of most industry analysts: anecdotal, unscientific (no random selection, no controls, no full disclosure of data, no double blinds) and unreviewed. Whether Glass is right or wrong, he is the one following best research practice, not Standish.
[This was brought to our attention in that excellent blog erp4it.com – thank-you Charlie]
Chicken ITle says we may be too pessimistic about our IT project performance. Sure we struggle, but the true measure of a project is not that it came in exactly on time and under budget (though that's good). It's that the project met the needs of the customer, and we often manage that, or close to it, despite being under-funded, making staff work on BAU and project at the same time, changing faster than people can absorb it, and trying to change too much at once.
Made in New Zealand 
