NHS IT project is dead, but why do large IT projects fail? Part 14

Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.

The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.

Here are the other parts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L’Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis,  part 12  John Worthy and part 13 Stuart Drew.

Today is the view of Milan Gupta, chief architect at Barclays bank.

He says: “Large IT projects fail for the simple reason that business moves a lot faster than large projects ever can. It’s a competitive world out there and to be on the cutting edge, agility is everything.

Gone are five year priority plans, today, businesses are living in the now adapting to market dynamics and eco-system changes daily. This does mean that by definition large IT projects are doomed to failure because by the time they’ve reached completion, the business has changed.

There are a number of things you can do to mitigate this risk by doing projects in smaller chunks – typically 90 days from user story specification to production. Some other core principles to accelerate project execution:  balanced business and technical leadership, small top-talent co-located teams, decreasing the layers of “translators” between the end customer and the developer, continuous integration, and test driven development. It is fatal to allow a development team to disappear for a year before they put their software into production.”


Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Interesting comments, but most of the really big project failures we've seen are in the public sector, where the business does not change all that fast. The problem instead is that the business is often so complicated that even the business users do not understand how it all works, especially the senior civil servants and politicians who are typically responsible for setting the overall scope, budget and timescale of the project. As the saying goes, most projects fail at the start, not at the end.

But Mr Gupta makes an excellent point about removing the layers between user and developer. Many projects - especially in these days of outsourcing/offshoring - suffer from the number of interfaces between individuals/departments/organisations that have to be negotiated every time a problem is identified or a question is asked. Add to this the tendency of suppliers to hide problems from the client, and the client's tendency to hide their ignorance of their own business requirements from these tiresomely inquisitive suppliers, and it is frankly amazing that any information ever makes it across these interfaces at all.

Agile approaches can make this situation worse, because the real requirements are only fully identified (or not) very late in the development process, so there is ample scope for mission creep, unresolved misunderstandings and nasty surprises.

Complex architectures and over-engineered designs can also add to this problem, especially in the public sector where both the client and the supplier think complexity is in itself a good thing (the client because it makes them feel special and gives them an excuse not to understand their own business, and the supplier because they can charge more for it). Some of this complexity may be inevitable, but in my experience you often end up with too many people in the process who see their roles as being mainly about generating confusion, complexity and obfuscation, rather than clarifying matters.

As for the idea of taking 90 days "from user story specification to production" in the public sector, dream on! I've spent longer than that trying to get an answer to a single question reqarding specific requirements on a government project.

Anyway, after several years working as an independent contractor on government projects, I could really do with working on the kind of project Mr Gupta describes...!