Comments on: IT project failure is widespread in Europe http://www.agilitysoftware.com/2007/07/24/it-project-failure-is-widespread-in-europe/ Business Led Computing Sun, 13 Jun 2010 15:32:01 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: francis carden http://www.agilitysoftware.com/2007/07/24/it-project-failure-is-widespread-in-europe/comment-page-1/#comment-106 francis carden Sat, 28 Jul 2007 21:55:17 +0000 http://www.workforceinabox.com/2007/07/24/it-project-failure-is-widespread-in-europe/#comment-106 Ciaran hit the NAIL on the HEAD !!! “Release early, release often” A 2006 Standish Survey reported for Application integration projects over $10m, nearly 39% are complete failures, 60% are over budget and very late and a miniscule 1% complete on time and budget... Agile Application Integration should be the new term.... Ciaran hit the NAIL on the HEAD !!!

“Release early, release often”

A 2006 Standish Survey reported for Application integration projects over $10m, nearly 39% are complete failures, 60% are over budget and very late and a miniscule 1% complete on time and budget…

Agile Application Integration should be the new term….

]]> By: Ciaran http://www.agilitysoftware.com/2007/07/24/it-project-failure-is-widespread-in-europe/comment-page-1/#comment-103 Ciaran Thu, 26 Jul 2007 21:55:06 +0000 http://www.workforceinabox.com/2007/07/24/it-project-failure-is-widespread-in-europe/#comment-103 Couldn't agree more. In addition to the points you've made, I have another - the larger the project, the more chance there is that when (or if - thankfully I've never experienced that) it is finally delivered, it doesn't meet the requirements in some way or other. This can be because the requirements weren't "well specified" in the first place, or because they changed in the meantime. I don't think this is something that can be fixed by specifying better in the first place, which is why I quoted the "well specified". I've seen some very well specified projects, conceived and designed by teams made of up both business and technical people who work well together. Nonetheless, each and every time, once something concrete takes shape, new requirements or enhancements come to mind from both sides of the table. In software development, the adage that encompasses the solution to the above is "Release early, release often", something I am a strong believer in. In the wider IT Project world, the equivalent would be to deliver the smallest possible subset of functionality that provides business benefit as soon as possible, and build from there. Which, now I read it back, is I think pretty much what you said in the first place. Hurrah! Couldn’t agree more. In addition to the points you’ve made, I have another – the larger the project, the more chance there is that when (or if – thankfully I’ve never experienced that) it is finally delivered, it doesn’t meet the requirements in some way or other. This can be because the requirements weren’t “well specified” in the first place, or because they changed in the meantime.

I don’t think this is something that can be fixed by specifying better in the first place, which is why I quoted the “well specified”. I’ve seen some very well specified projects, conceived and designed by teams made of up both business and technical people who work well together. Nonetheless, each and every time, once something concrete takes shape, new requirements or enhancements come to mind from both sides of the table.

In software development, the adage that encompasses the solution to the above is “Release early, release often”, something I am a strong believer in. In the wider IT Project world, the equivalent would be to deliver the smallest possible subset of functionality that provides business benefit as soon as possible, and build from there. Which, now I read it back, is I think pretty much what you said in the first place. Hurrah!

]]>