It found that 37 percent of the software development projects in its study were successful, meaning they came in on time, on budget and the users accepted them. It categorized 42 percent of the projects as challenged. These are projects that had problems such as being late, over budget, or didn't have everything users wanted. The remaining 21 percent were failures, meaning they weren't completed or were rejected by the customer.
But the success rate of projects improved by 5 percent from two years ago, said Jim Johnson, the chairman of Standish. That may be due to more agile projects, as well as the types of projects undertaken during the recession, including fewer ERP installations.
Johnson offers caveats to the report's finding. Project failure for instance, can be a good thing.
"If a firm doesn't have any failures they are not pushing the envelope," said Johnson, who cites Apple's development history, which included failures that nonetheless have helped spawn successful products.
Johnson said an important key to a successful project is having a strong executive sponsor.
"People don't make decisions very quickly and I think that's the death knell for projects," Johnson said. The reason the agile process works so well "is because it creates velocity" that leads to fast decisions.
Also key, said Johnson, is project optimization, or focusing on what's important. "Too many of them grow out of control, and you really need to focus on the real high value items and work on those, and I think that's one of the things the agile process does," he said.
Ben Blanquera, who led agile development as vice president of IT at Progressive Medical in Columbus, Ohio, and is now a consultant, said the "premise with agile is you can break these things up to what is the smallest piece, the most viable product."
"The notion here is fast feedback," said Blanquera, "there has to be rapid iteration."
Standish's categorizations are debated.
The danger with the "challenge" definition, said Little, is that many of the projects that were delivered late or had less scope than originally intended, "were nonetheless successful in the eyes of the business."
Agile has its own issues as well.
Barry Boehm, the director of the University of Southern California Center for Systems and Software Engineering, said agile is good at getting a project fielded early and evolving it as necessary, but it does have "some failure modes."
One problem with agile is what's called "easiest first" or "technical debt," which basically means that a developer, in the interest of pleasing users and customers, may, for instance, put everything in main memory "and the thing performs like a flash and the users love it" until eventually nothing fits in main memory anymore "and you have something that is an architectural breaker."
Developers may hold off putting in security features until a later point in the development, at which they have already put in so many insecure features that there is no way to work security into it later, Boehm said.
Agile is good for smaller projects, and where the requirements are rapidly changing. It also works "in an organization where people feel comfortable or empowered," said Boehm.
Patrick Thibodeau covers SaaS and enterprise applications, outsourcing, government IT policies, data centers and IT workforce issues for Computerworld. Follow Patrick on Twitter at @DCgov or subscribe to Patrick's RSS feed. His email address is firstname.lastname@example.org.
Read more about project management in Computerworld's Project Management Topic Center.