We’ve all seen the surveys that talk about how miserable the industry is in general at doing software projects. Failure rates of up to 85% are commonly sited. Have you ever stopped to ask “What is the definition of failure?”. Scott Ambler did, and once you define failure (or success), you get a much different picture of the industry in general.
Think about it for a minute – how would YOU define success for your projects?
When Scott asked that question, here is the result based on 600 respondents:
In short, we appear to value delivering high-quality working software that meets the needs of our stakeholders in a cost effective manner while respecting the needs of the people involved with the project. This is more important to us than building something to specification on schedule and on budget, regardless of the toll it takes on the people involved.
This is a very different picture of success than the definition used by Standish Group’s Chaos Report … They define success as “on time, on budget, meeting the spec”, but that definition doesn’t seem to hold when we ask people what they actually value.
So specifically, how did the IT industry define project success? From Scott’s survey data:
- Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
- Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
- Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
- Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
- Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.
So using actual success criteria, what is the success rate of IT projects? Is it really only 15%? Well, it is actually much better than that. Again from Scott’s survey results:
Respondents reported that Agile software development projects have a 71.5% success rate, traditional projects a 62.8% success rate, and offshored software development projects a 42.7% success rate.
Notice, these are SUCCESS rates, not failure rates. Quite a different picture of the industry in general.
I think it is important to look at the data yourself. Some of the really interesting information to me is the differences in success definition between different kinds of project participants. For example, the success criteria as stated by project managers is very different than that expressed by the other project participants. It is also interesting to see that the business stakeholders place a very low value on the actual working environment, while that is of great concern to the development staff . What this tells me is that different members of the project team have different goals, which are often in conflict with each other. And what I find in my work, is that those different goals are generally UNSTATED assumptions being made by the different team members. So everyone talks about having a successful project, but no one talks about what that actually means.
I think Scott’s article and survey data are important to open up discussions within your organization about what success means to the various members of IT. You cannot move a boat forward if everyone is rowing in different directions, and you cannot effectively steer a project team to success if there is not agreement on what success means.
I encourage you to look over the report and the survey data and to start discussions in your organization.