IT project failure is widespread in Europe

Here’s some stunning research reported by the BBC that I’ve only just found.  A European study by HP and The Economist found depressingly few IT projects being delivered on time with the major culprits being:

a)  outsourcing
b)  changing priorities
c)  poor co-ordination between managers

Further depression emerges in the lack of accountability.  IT people are reportedly not being charged with taking responsibility for the late delivery.

My first reaction was that this smacks of mis-management in IT.  But then I wondered if the responsibility should be jointly held between IT and the business.  Every IT project is there to serve a business end in some way.  Therefore IT can only provide what the business users want and if they change their mind, then the project slips.

Business people argue that the world moves quickly and the organisation’s priorities have to move with same speed.

So we end up in a position I have seen more than once – a project is a rolling 6 months away from implementation and never actually completes.

The only solution I can see is to make projects smaller.  Smaller deliverables, delivered faster with incremental but real business benefit.  Also the smaller the project, the less the need for outsourcing which keeps closer control and better team motivation.  This is not a guarantee against the business outgrowing the need for the solution when it is delivered but it does make for a better chance of getting something beneficial delivered rather than a monstrously large project stuck up its own arse and unable to produce anything of use.

There still needs to be some co-ordination by way of programme management, of course.  Smaller projects are building blocks towards a greater goal.  However, the important (and sometimes conceptually difficult) thing is to try to make each smaller project stand on its own business case and deliver a unique, isolated, and non-dependent benefit.

2 Responses to “IT project failure is widespread in Europe”

  1. Ciaran Says:

    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!

  2. francis carden Says:

    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….

Leave a Reply