Interesting stat you have there. Where did you get the "80%" from?
The most recent figures I have are from the 2009 Chaos Report:
On the success side, the average is only 16.2% for software projects that are completed ontime and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.
These figures could be depressing, but what they actually mean is that we are working in a fascinating field where many new things are left to be learnt. I love the conclusion of the Chaos report:
There is one final aspect to be considered in any degree of project failure. All success is rooted in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge. Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful.
If we 'believe' in a method, become emotionally invested in it, then we are denying ourselves the opportunity to reflect critically on what we do. We fail to learn new and better ways.
What about that "20%" that must be getting it right? We're they lucky? Has their luck made them arrogant?
Have you ever watched the apprentice. Both teams make stupid mistakes but one team gets lucky. The lucky team are whisked off for a treat while the unlucky team get pulled back into the boardroom for a firing.
Something similar happens in companies. "20%" of the projets get lucky and succeed. Those lucky individuals get promoted to a position where they get to define the approach for everybody. They believe that if everybody else just does what they did then they will all succeed. They push out their changes based on their distorted views and the company suffers. When the changes fail to bring success they say "our approach is proven, the problem must be with the people."
I don't like the idea of it just being about having the right people. Other fields have shown that a good method can make a huge difference.
It's just one piece of paper. What difference did this single piece of paper make?
The number of deaths was nearly halved.
In the pilot study "the inpatient death rate following major operations fell from 1.5% to 0.8% after implementation of the checklist."
People lived because the surgical team followed an improved process.
Same people; improved method; better outcome.
The rate of major inpatient complications dropped from 11% to 7%,
The people didn't change. The process did.
Of particular interest is Gawande's first attempt at the checklist. It's an epic fail. He learns from the experience.
On 18 June[masked]:53, Anatoli <[address removed]>
Speaking about beliefs, how can anyone be a 'true believer' in anything in our industry? :) Just trying to define what Agile actually is will derail any discussion.
I 'believe' in common sense and competent people (at all levels, not just developers!) -- they can do it with waterfall just as good as they can do it with Agile (whatever that means!) or any other method. In fact, they will do it without any strictly defined method. They'll just do it as they have been doing it for decades.
Yes, we all know that 80% of all software projects end up in tears (which is actually consistent with the rest of the Universe so it's hardly a shocking or unusual statistic -- why should we be different from everybody else?), but obviously in 20% of cases people were getting it right :) Must be people and not the method which did the trick.
This message was sent by Anatoli ([address removed]) from LJC - London Java Community.
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
To learn more about Anatoli, visit his/her member profile