Software development projects have always been challenging. The most referenced source for metrics about project success is the Standish Group yearly CHAOS report. According to this source, around 30% of software development project were considered as a “failure” in the recent years. The failure rate of larger projects is a little bit higher than the average and the rate of failure of Agile projects a little bit lower than average.
Initially, some people thought that Agile would be the “cure” for all software development projects issues. I remember reading that if an Agile project failed, it was because it wasn’t truly Agile. The fact is that one of the key benefit of Agile should be a quicker feedback loop. It will however not remove the fact that you might be working with unskilled product owners or developers, that the chosen technology is not adequate to support the software product or that the expected value of the project doesn’t materialize. Even Google that is supposed to employ some of the brightest people in the technology world can produce a project like Google Glass that went from hyperhype to silent death when it hit the real world.
For small organizations with limited resources, measuring value creations and detecting issues or failures quickly is a matter of survival. This is however not necessary the case in larger organizations where failures are still mainly considered as bad things and generate blame. The goal of the project manager is to deliver results, not to kill projects. We can still dream of a software development world where you would be proud of having on your resume the fact that you stopped a project after two months and saved your company a lot of money. Most people will only consider the money that was spent for “nothing”. There are however many cases where admitting failure could be the greatest success for a software development project and avoid wasting efforts and resources.
I wish all the Methods & Tools readers and their family a healthy 2016. I would also like to thank the authors and the advertisers for their contribution and their support that help Methods & Tools to start with confidence its 24th year of existence. You can help us also us as a reader by telling your colleagues or social network relationship that you have read something interesting in Methods & Tools.
References
The Standish Group International https://www.standishgroup.com/
Blame. Language. Sharing. http://fractio.nl/2015/10/30/blame-language-sharing/
Why Organizations Don’t Learn https://hbr.org/2015/11/why-organizations-dont-learn