1. Software Development Project Success Survey 2008
Scott W. Ambler
Copyright 2009 Scott W. Ambler

2. How To Use These Slides
I have provided these slides, and the raw data behind them, so that others can use them in their own work.
You may reuse all, or a part of, this slide deck as long as you provide a clear reference to the source.
The suggested reference is: Results from Scott Ambler’s December 2008 Software Development Project Success Survey posted at
Most slides have “speaker notes”
Copyright 2009 Scott W. Ambler

3. Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/
The Survey
December 2008
sent to DDJ mailing list
279 respondents
59% were developers/modelers, 25% were in management
80% had 10+ years in IT
16% worked in orgs of IT people
92% worked in commercial firms
68% North American, 16% European
Overall goal was to explore how IT professionals define project success.
Copyright 2009 Scott W. Ambler

4. Project Success Rate by Paradigm
Success as defined by the respondent (this is the same for all slides in this deck). See other slides for how IT professionals define success in practice
Success rate calculated by summarizing the weighted average of each range (i.e % averages to 95%) times the number of respondents. Same approach taken for other slides too.
Definitions used in the survey:
On an ad-hoc software development project the team does not follow a defined process.
On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP.
On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP.
On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes.
Copyright 2009 Scott W. Ambler

5. Success Rate by Project Type
Copyright 2009 Scott W. Ambler

6. How People Define Success
Functionality: 83% believe that meeting actual needs of stakeholders is more important than building the system to specification
Quality: 82% believe that delivering high quality is more important than delivering on time and on budget
Money: 70% believe that providing the best ROI is more important than delivering under budget
Schedule: 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule
It is critical to understand how people actually define process success. The definition of “on time, on budget, meeting the spec” doesn’t seem to hold when we actually ask people what they value.
Copyright 2009 Scott W. Ambler

7. Effectiveness of Development Paradigms
The greater the score the better the paradigm was at addressing that success factor.
Score is calculated as follows: (#Very Effective * 10 + #Effective *5 - #Ineffective*5 - #Very Ineffective*10)/#Respondents
Definitions used in the survey:
On an ad-hoc software development project the team does not follow a defined process.
On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP.
On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP.
On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes.
Copyright 2009 Scott W. Ambler

8. Iterative Project Success Rates
The more distributed a team is, the greater the risk
Definitions used in the survey:
On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP.
Co-located teams: Everyone, including primary stakeholders, are in the same room.
Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be.
Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team.
Copyright 2009 Scott W. Ambler

9. Agile Project Success Rates
The more distributed a team is, the greater the risk
Definitions used in the survey:
On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP.
Co-located teams: Everyone, including primary stakeholders, are in the same room.
Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be.
Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team.
Copyright 2009 Scott W. Ambler

10. Traditional Project Success Rates
The more distributed a team is, the greater the risk
Definitions used in the survey:
On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes.
Co-located teams: Everyone, including primary stakeholders, are in the same room.
Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be.
Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team.
Copyright 2009 Scott W. Ambler

11. Ad-Hoc Project Success Rates
The more distributed a team is, the greater the risk
Definitions used in the survey:
On an ad-hoc software development project the team does not follow a defined process
Co-located teams: Everyone, including primary stakeholders, are in the same room.
Near-located teams: Some people may be in cubes, or on different floors, or different buildings, or working from home BUT everyone is in the same geographic area and could potentially get together each day for a physical group meeting if need be.
Far-located teams: Some people are at such a distance that they would need to take a plane to attend a physical meeting of the entire team.
Copyright 2009 Scott W. Ambler

12. Success Rate by Paradigm and Distribution
Success as defined by the respondent (this is the same for all slides in this deck). See other slides for how IT professionals define success in practice
Calculated by summarizing the weighted average of each range (i.e % averages to 95%) times the number of respondents. Same approach taken for other slides too.
Definitions used in the survey:
On an ad-hoc software development project the team does not follow a defined process.
On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP.
On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP.
On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes.
Copyright 2009 Scott W. Ambler