Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Success is in the Eye of the Beholder Differences Between Paradigms Agile and Iterative Work Better

We don't really know much about the level of success on software development projects. Many people refer to the Chaos Report by the Standish Group which reports that 34% of IT projects are successful, 51% challenged (over schedule, and/or over time, and/or missing significant functionality), and 15% of projects are considered failures. However, at Dr. Dobb's we've found time and again that those numbers simply don't reflect the actual success rates being experienced by our readership. Don't get me wrong, I have no doubt that only one third of development projects are reasonably on time, on budget, and deliver pretty much what people want. But what I do doubt is that people actually measure project success in those terms.

In December 2008 we sent a survey out to the Dr. Dobb's mailing list and 279 people responded. Of the 279 59% were developers/modelers and 25% were in management, 80% had 10 or more years in IT, 16% worked in orgs of 1000 or more IT people, 92% worked in commercial firms, 68% were North American, and 16% European. The goals of the survey were to determine how people actually define project success and then how successful various approaches to software development proved to be in practice.

Success is in the Eye of the Beholder

We asked about four factors which we believe are critical issues for software development projects: functionality delivered, quality delivered, effective use of funds, and schedule. When it comes to functionality delivered, 83% believe that meeting actual needs of stakeholders is more important than building the system to specification. Similarly, 82% believe that delivering high quality is more important than delivering on time and on budget. Effective use of development funds is also important, with 70% believing that providing the best ROI is more important than delivering under budget. Finally, when it comes to schedule 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule.

What we found isn't surprising, but it clearly questions the "on time, on budget, to specification" definition of success. More specifically, of the 271 people who indicated how they defined success, only 11 (4%) indicated that a software development project must be on time, on budget, and to specification. More important, not one of the business stakeholders who responded to the survey believed in this definition of success. Interestingly, 122 respondents (45%) indicated that were flexible on all three factors.

There are several important observations to make:

• First, different people define project success in different ways, one size does not fit all. One of the criticisms that I get about the surveys that I run is that it's hard to judge the true success rates of projects because I'm not inflicting (and I use that word on purpose) a specific definition of success. Interesting opinion, but as you'll soon see that's not really an issue. I instead turn this criticism around and question any research that did insist on a specific definition of success.
• Second, different project teams within the same organization will have different success criteria, so once again one size does not fit all. For example, a project team within a bank producing a customer-facing informational web site will have different success criteria than a team who is working on an internal web site, and both will differ from the criteria for a team working on their funds transfer system.
• Third, the stakeholders should drive the success criteria for a project, a fairly obvious concept that we appear to be struggling with as an industry. Although few stakeholders seem interested in "on time, on budget, to specification" they often ask for this on many projects, I suspect because they expect little better of us. As professionals we need to start giving them more effective options.
• Fourth, it seems strange that only 4% of people defined success as on time, on budget, and to specification considering how often we seem to be asked for that. This to me is a clear indication that we should be giving people choices, the implication being that we would actually need to be sufficiently skilled to deliver software when it's ready to be shipped, spend our IT investment wisely, and build software which meets the actual needs of stakeholders.

1 Success is in the Eye of the Beholder | 2 Differences Between Paradigms | 3 Agile and Iterative Work Better Next Page

RELATED ARTICLES Other Voices: Knowledge Management Basics Inform System Release Lifecycle Server+client Fusion: An Architectual Proposal The Power of 'Random' JDBC Fast Connection Failover with Oracle RAC Micro Focus Rolls Out Visual Studio 2010 Support		TOP 5 ARTICLES No Top Articles.