Chaos Is Back

Computerworld - We're losing ground. Only 28% of IT projects succeed these days, down from 34% a year or two ago. Outright failures -- IT projects canceled before completion -- are up to 18% from 15%. The remaining 51% of IT projects are "challenged" -- seriously late, over budget and lacking expected features.
Those numbers are from the just-completed Chaos report from The Standish Group. Standish has been doing this study since 1994, and ever since, we've been steadily improving our ability to deliver projects. A decade ago, only 16% of IT projects were successes. By last year, it was twice that. Now we're backsliding.
How did we get headed in the wrong direction?
When I talked to Standish Chairman Jim Johnson, the numbers were still being crunched. But he pointed to a few significant details. For one: Projects are getting more expensive, and big projects are more likely to fail.
For another: As projects get bigger, we're no longer keeping our work iterative. We've gone back to more traditional development practices -- practices with higher failure rates.
For a third: Lack of user involvement has jumped back to the top position among reasons for IT project failure. But lack of executive support is still running a very close second. Without committed executive sponsors and involved users, our projects fail.
Johnson told me the key to success is scope management. If you can keep projects tight and focused, avoid bloated feature wish lists and watch out for explosive requirements such as, "The new system must do what the old system did," you can do OK.
Maybe he's right. But I think we need to do more than just avoid scope creep.
One reason I like the Chaos study is that Standish counts up the results of lots of real projects, and it has been doing that for long enough that we can see real trends. So we know that our biggest success rate for IT projects came right in the middle of the recent downturn. After the bubble burst, budgets were tight, resources were strained and big projects were rare.
And -- not coincidentally -- our success rate jumped and our project cancellation rate dropped. When projects are small, we succeed.
That suggests that we don't just need to keep projects from getting too big. We need to work actively to dismantle big projects.
Chop a big project down into smaller projects and three things happen. First, everything's simpler. We can use smaller, more focused teams. We can deal with a limited