With software, smaller is better

Organizations that build smaller software projects that are rolled out in quick, phased release cycles tend to be more productive and have higher success rates, according to analysts at the Cutter Consortium who are taking a look at why software projects fail.

Last week, the analyst firm released a pair of reports that are the first in a series focusing on failed software projects. The first, titled "Does Project Size Matter," found that while project size was irrelevant when it came to canceling software development efforts, smaller projects ultimately had greater success.

"There is an increasing understanding that [software] development that is done in smaller iterations tends to be more successful," says Khaled El Emam, senior consultant at the Cutter Consortium. He recommends to his clients that are building IT systems that they roll out an initial software architecture and then add features and functions in phased releases spread about three months apart.

"Spend six to nine months on first release of a system, then have three-month iterations after that," El Emam says. "That way the first release allows the team to design the system properly and put in place a good architecture for the future releases instead of trying to build the whole thing at once."

El Emam looked at more than 230 recently completed software projects to understand how the size of the project - length of time and number of developers - affected the success or failure of the undertaking. Most surprising was the fact that size didn't affect decisions to cancel a the cancellation rate was so small," he says.

El Emam found that just 15% of the organizations he surveyed canceled projects.

"Things are getting better and IT departments and project managers are better able to manage these projects," he says, noting that new software development practices are helping to keep projects alive and make them successful. For example, there is more focus today on user participation in the development process, he says.

"The main reason why projects typically fail is that you build something for the users, but the users don't participate in the project. So you build something, and it's not what the users need," El Emam says. "Today, there is a stronger emphasis on peer reviews and better testing practices."

A second report, "Software Project Failures: Part 1 - Should We Quit Now or Later," by Cutter Consortium senior analyst E.M. Bennatan, focused on software failures and how companies handle them.

Bennatan studied software project failures at 200 organizations during the past three years. Of those, 44% had canceled or abandoned software projects because of serious problems, including budget overruns, schedule overruns or quality problems.

"Not all failed projects get canceled," Bennatan writes in the report. "Many are completed but perceived as failures because of severe overruns and/or quality problems."

These projects are the ones that went on for too long and probably could have been remedied earlier, Bennatan says.